Celestin Apprentice 5/Apprentice-Release5.iso/Information/CSMP Digest/volume 3/csmp-digest-v3-082

Text File | 1995-12-31 | 62.6 KB | 1,664 lines | [TEXT/R*ch]

C.S.M.P. Digest             Wed, 08 Feb 95       Volume 3 : Issue 82

Today's Topics:

        Bit Blitting vs. CopyBits
        File system persistence
        HandAndHand Question
        MacOS  SDK quick impressions
        NIM Routines that Move or Purge Memory
        Simulating Drag-to-Trash
        Sprite Animation Toolkit 2.3a2 available
        StandardGetFile behavior
        What causes "odd address 0x40be14" error?
        Where can I find some game source code?



The Comp.Sys.Mac.Programmer Digest is moderated by Francois Pottier
([e-mail]).

The digest is a collection of article threads from the internet newsgroup
comp.sys.mac.programmer.  It is designed for people who read c.s.m.p. semi-
regularly and want an archive of the discussions.  If you don't know what a
newsgroup is, you probably don't have access to it.  Ask your systems
administrator(s) for details.  If you don't have access to news, you may
still be able to post messages to the group by using a mail server like
anon.penet.fi (mail [e-mail] for more information).

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
nef.ens.fr).  Article threads are not added to the digest until the last
article added to the thread is at least two weeks old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The digest is officially distributed by two means, by email and ftp.

If you want to receive the digest by mail, send email to [e-mail]
with no subject and one of the following commands as body:
    help                                Sends you a summary of commands
    subscribe csmp-digest Your Name     Adds you to the mailing list
    signoff csmp-digest                 Removes you from the list
Once you have subscribed, you will automatically receive each new
issue as it is created.

The official ftp info is //ftp.dartmouth.edu/pub/csmp-digest.
Questions related to the ftp site should be directed to
[e-mail]. Currently no previous volumes of the CSMP
digest are available there.

Also, the digests are available to WAIS users.  To search back issues
with WAIS, use comp.sys.mac.programmer.src. With Mosaic, use
http://www.wais.com/wais-dbs/comp.sys.mac.programmer.html.


-------------------------------------------------------

>From [e-mail] (Jared O'Neal)
Subject: Bit Blitting vs. CopyBits
Date: Thu, 12 Jan 1995 12:22:20 +0000
Organization: The Wonderful World of Weinerschnitzel!?!

I've found that CopyBits works quite fast in most instances, but now I'm
beginning to wonder how it compares to well-written, custom bit blitters.
Is it worth the time and effort to write a custom blitter, or should I
just stick with CopyBits?

And off the subject, can anyone name a good book for learning 68000 assembly?

TIA!


--jared



+++++++++++++++++++++++++++

>From [e-mail] (Ken Long)
Date: Fri, 13 Jan 1995 02:30:09 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

Jared O'Neal ([e-mail]) wrote:
: I've found that CopyBits works quite fast in most instances, but now I'm
: beginning to wonder how it compares to well-written, custom bit blitters.
: Is it worth the time and effort to write a custom blitter, or should I
: just stick with CopyBits?

You could just look at one that's already been written and compare them,
couldn't you?  That is, SpriteWorld has one in the source, that's called
from a menu item.

But i've seen a BIG difference in speed while running something on the
68040/33mhz compared to the 68020/16mhz I'm using right now.  I'd assume
a PowerMac beats the '040, as well.  So, as far as getting stuff drawn
fast goes, there is a speed limit for user friendliness.  Some games that
a 46 year-old can handle just fine on my LC are just too damned fast on
the '040/33.  A 13 year-old high on caffine may be able to keep up, but
not me.

How fast is fast enough?

-Ken-


+++++++++++++++++++++++++++

>From [e-mail] (Bob Bradley)
Date: Thu, 12 Jan 1995 19:09:02 -0800
Organization: SS Software Inc.

In article <[e-mail]>,
[e-mail] (Jared O'Neal) wrote:

> I've found that CopyBits works quite fast in most instances, but now I'm
> beginning to wonder how it compares to well-written, custom bit blitters.
> Is it worth the time and effort to write a custom blitter, or should I
> just stick with CopyBits?

Just stick with CopyBits. The best way to go about it is to write
everything using QuickDraw and get it working solidly. Then see if it's
fast enough. If not, find out where you're spending the most time, and
optimize. CopyBits is EXTREMELY fast considering what it does. It does
everything for you and does it correctly. Unless you have a very specific
case where you know almost everything about the machine and conditions it
will be running under, it will be difficult to beat CopyBits.

+++++++++++++++++++++++++++

>From [e-mail] (Ingemar Ragnemalm)
Date: 13 Jan 1995 23:13:04 GMT
Organization: (none)

[e-mail] (Jared O'Neal) writes:

>I've found that CopyBits works quite fast in most instances, but now I'm
>beginning to wonder how it compares to well-written, custom bit blitters.
>Is it worth the time and effort to write a custom blitter, or should I
>just stick with CopyBits?

For copying large areas, CopyBits is very hard to beat. For copying small
areas, like sprites, a blitter makes a big difference.

I recommend that games have an option to select QuickDraw (CopyBits) or
custom code. That way, users can just skip your blitter if it fails on
some configuration.

--
- -
Ingemar Ragnemalm, PhD
Image processing, Mac shareware games
E-mail address: [e-mail] or [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Juri Munkki)
Date: 20 Jan 1995 22:18:11 GMT
Organization: Helsinki University of Technology

In article <3f7f12$[e-mail]> Steve Lemke <[e-mail]> writes:
>[e-mail] (Bob Bradley) wrote:
>One thing I recommend for people who insist on doing it the hard
>way (that is, to write it themselves) is to include an OPTION for
>the user to use CopyBits.  Writing directly to the screen is a bad
>idea...  But if you must do it, be SURE to include the requisite
>calls to ShieldCursor and ShowCursor (even if the cursor is not
>visible).

It's even more important to call SwapMMUMode. ShieldCursor is also
a good idea, but forgetting to call SwapMMUMode when you should will
usually crash whereas forgetting to call ShieldCursor mostly causes
screen update problems. Do both.

Having an option to use CopyBits is very nice and recommended when it
is possible. From experience, I can tell that most people are not
capable of writing 100% compatible code because they simply do not
have the hardware to test all the possible configurations. On the
other hand, I know that an experienced Mac programmer (like myself)
can write code that is 99.999% compatible. (Unfortunately there
are millions of Macs out there.)

CopyBits has bugs too...we found one in the latest version last month
while trying to solve an obscure problem in our program. I found another
one about nine months ago. Obscure stuff that only happens in thousands
or millions of colors, but definitely bugs. (I guess I should dig up the
bug reporter and send the 30-line program that demonstrates the new one
we found... that one was good enough for a "Develop" puzzle page.)

--
  Juri Munkki                   There ain't no such thing as a shareware lunch.
 [e-mail]                         Windsurfing: Faster than the wind.

---------------------------

>From [e-mail] (Jerry Halstead)
Subject: File system persistence
Date: Tue, 10 Jan 1995 10:42:39 -0500
Organization: The Synclavier Company

Do devices/volumes have a unique identifier that is
persistent after rebooting?

I'd like to make my application "remember" which window(s)
the user had open and attempt to re-open them the next time the
application is launched.  The windows in this case are listings
of folder contents and could be from any mounted drive.
How does the finder do this?  It remembers which folder is open
and the location.  Is this an attribute of the info in the
desktop database?

Here is where I have problems.  Most Mac hard drives come out
of the box name "Macintosh HD".  Let's say the user just bought
a new hard drive and now has two "Macintosh HD" named drives on
thier desktop.  This rules out saving the volume name as a string.
And, according to IM/TR, the vRefNum changes each time a volume is
mounted, so it isn't useful.

What I need, it seems, is a unique ID that is persistent across
boots (and accessible for appleshare volumes).  Combined with the
volume name this seems like it would allow me to get an FSSpec
for each volume, despite name conflicts.

Has anyone done this?  Any ideas?

-Jerry

--
 Optimist:  "The glass is half full."
 Pessimist: "The glass is half empty."
 Engineer:  "The glass is twice as big as it needs to be."
 Product Dev: "That's not the half we specified to be full"
 Marketing:   "The other half will be filled by release."

+++++++++++++++++++++++++++

>From [e-mail] (Quinn "The Eskimo!")
Date: Wed, 11 Jan 1995 10:29:39 +0800
Organization: Department of Computer Science, University of Western Australia

In article <[e-mail]>,
[e-mail] (Jerry Halstead) wrote:

>Do devices/volumes have a unique identifier that is
>persistent after rebooting?

Use aliases.  This is what they were designed for.

>How does the finder do this?

I just figured this out the other week and you definitely do not want to
know (:  OK, so I'll tell you anyway... the Finder remembers the list of
open folders on a volume by recording the dirID of the first folder in the
volume header (right next to the dirID of the System Folder) and then
chaining the list of folders behind that folder using frOpenChain field of
the DXInfo of the folders.  Can anyone say *ugly!*

Share and Enjoy.
--
Quinn "The Eskimo!"  "Ah, so that's the secret,
                      if only Captain Bipto had known.

+++++++++++++++++++++++++++

>From [e-mail] (Steve Caine)
Date: Wed, 11 Jan 1995 04:02:08 GMT
Organization: The World @ Software Tool & Die

In article <[e-mail]>,
[e-mail] (Jerry Halstead) wrote:

> Do devices/volumes have a unique identifier that is
> persistent after rebooting?

How about using the volume name and creation date? The latter is almost
certain to unique among all mounted volumes (although it will change when
the user reformats the drive).

--
Steve Caine                            "Life is a comedy to those who think,
North Atlantic Publishing Systems Inc.  and a tragedy to those who feel."

+++++++++++++++++++++++++++

>From [e-mail] (Jim Reekes)
Date: Tue, 10 Jan 1995 21:37:16 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>,
[e-mail] (Jerry Halstead) wrote:

> Do devices/volumes have a unique identifier that is
> persistent after rebooting?
>
> I'd like to make my application "remember" which window(s)
> the user had open and attempt to re-open them the next time the
> application is launched.  The windows in this case are listings
> of folder contents and could be from any mounted drive.
> How does the finder do this?  It remembers which folder is open
> and the location.  Is this an attribute of the info in the
> desktop database?
>
> Here is where I have problems.  Most Mac hard drives come out
> of the box name "Macintosh HD".  Let's say the user just bought
> a new hard drive and now has two "Macintosh HD" named drives on
> thier desktop.  This rules out saving the volume name as a string.
> And, according to IM/TR, the vRefNum changes each time a volume is
> mounted, so it isn't useful.
>
> What I need, it seems, is a unique ID that is persistent across
> boots (and accessible for appleshare volumes).  Combined with the
> volume name this seems like it would allow me to get an FSSpec
> for each volume, despite name conflicts.
>
> Has anyone done this?  Any ideas?

You're suppose to be using aliases for this function. For pre-system 7
users, you have to save the volume name, dirID, and file name.

--
Jim Reekes, Polterzeitgeist |       QuickTime Products R&D
                            |        Sound Manager Expert
Apple Computer, Inc.        | "All opinions expressed are mine, and
2 Infinite Loop  MS 302-3KS |  do not necessarily represent those
Cupertino, CA 95014         |  of my employer, Apple Computer Inc."

+++++++++++++++++++++++++++

>From Mark Williams <[e-mail]>
Date: Mon, 23 Jan 1995 08:30:05 GMT
Organization: Streetly Software


In article <[e-mail]>, Jim Reekes writes:

>
> In article <[e-mail]>,
> [e-mail] (Jerry Halstead) wrote:
>
> > Do devices/volumes have a unique identifier that is
> > persistent after rebooting?
> >
> > Here is where I have problems.  Most Mac hard drives come out
> > of the box name "Macintosh HD".  Let's say the user just bought
> > a new hard drive and now has two "Macintosh HD" named drives on
> > thier desktop.  This rules out saving the volume name as a string.
> > And, according to IM/TR, the vRefNum changes each time a volume is
> > mounted, so it isn't useful.
> >
> > What I need, it seems, is a unique ID that is persistent across
> > boots (and accessible for appleshare volumes).  Combined with the
> > volume name this seems like it would allow me to get an FSSpec
> > for each volume, despite name conflicts.
> >
> > Has anyone done this?  Any ideas?
>
> You're suppose to be using aliases for this function. For pre-system 7
> users, you have to save the volume name, dirID, and file name.

Aliases are best. If you _are_ stuck with pre-system 7 you could use
the volume creation date to distinguish drives with the same name -
in fact the creation date is going to be more reliable than the name. If
you find a volume with the same cd but different name, you can bet its
been renamed.

Mark Williams

---------------------------

>From [e-mail] (Doug Williams)
Subject: HandAndHand Question
Date: 21 Jan 1995 06:25:20 GMT
Organization: University of Arizona, Tucson, AZ

Can someone answer what should be a simple question about
HandAndHand?.  In the code below, if I take out the call to
NewHandle(0), the HandAndHand call returns -109, which Macsbug says
means that "Handle was NIL" -- no kidding.  My first question is
whether a call to NewHandle(0) is a bad thing.  I seem to recall such
a thread a while ago.  The second question is why do I need that call
at all.  I (maybe naively) would assume that HandAndHand should be
able to deal with any valid Handle.  Is there really such a huge
difference between a NULL Handle and a zero length Handle?  Is my
problem akin to declaring a pointer to a struct but not allocating the
memory for the struct?


        Handle  tempH = NULL;
        Handle tempH2 = NULL;
        Str255 tempStr = "\ptemp string";
        OSErr myErr;

        PtrToHand(&tempStr[1], &tempH, tempStr[0]);
        tempH2 = NewHandle(0);
        myErr = HandAndHand(tempH, tempH2);


-=-doug-=-

+++++++++++++++++++++++++++

>From [e-mail] (Brian Stern)
Date: 21 Jan 1995 15:48:50 GMT
Organization: The University of Texas at Austin, Austin, Texas

In article <3fq9cg$[e-mail]>, [e-mail]
(Doug Williams) wrote:

< Can someone answer what should be a simple question about
< HandAndHand?.  In the code below, if I take out the call to
< NewHandle(0), the HandAndHand call returns -109, which Macsbug says
< means that "Handle was NIL" -- no kidding.  My first question is
< whether a call to NewHandle(0) is a bad thing.  I seem to recall such
< a thread a while ago.  The second question is why do I need that call
< at all.  I (maybe naively) would assume that HandAndHand should be
< able to deal with any valid Handle.  Is there really such a huge
< difference between a NULL Handle and a zero length Handle?  Is my
< problem akin to declaring a pointer to a struct but not allocating the
< memory for the struct?
<
<
<         Handle  tempH = NULL;
<         Handle tempH2 = NULL;
<         Str255 tempStr = "\ptemp string";
<         OSErr myErr;
<
<         PtrToHand(&tempStr[1], &tempH, tempStr[0]);
<         tempH2 = NewHandle(0);
<         myErr = HandAndHand(tempH, tempH2);
<
<
< -=-doug-=-

Calling NewHandle() with a length of zero is just fine.

HandAndHand requires two valid handles.  NULL is not a valid handle.
Handles ONLY come from the memory manager.  You have to request one.  Some
toolbox calls request one for you, like in PtrToHand, or GetResource.  The
following line allocates space for a handle but doesn't create one:

        Handle  tempH = NULL;

You need to understand that a Mac Handle is not just a pointer to a
pointer.  It is a pointer to a Memory Manager data structure.

Good luck,

--
Brian  Stern  :-{)}
Toolbox commando and Menu bard
[e-mail]

+++++++++++++++++++++++++++

>From Mark Williams <[e-mail]>
Date: Mon, 23 Jan 1995 08:55:01 GMT
Organization: Streetly Software


In article <3fq9cg$[e-mail]>, Doug Williams writes:

>
> Can someone answer what should be a simple question about
> HandAndHand?.  In the code below, if I take out the call to
> NewHandle(0), the HandAndHand call returns -109, which Macsbug says
> means that "Handle was NIL" -- no kidding.  My first question is
> whether a call to NewHandle(0) is a bad thing.  I seem to recall such
> a thread a while ago.  The second question is why do I need that call
> at all.  I (maybe naively) would assume that HandAndHand should be
> able to deal with any valid Handle.  Is there really such a huge
> difference between a NULL Handle and a zero length Handle?  Is my
> problem akin to declaring a pointer to a struct but not allocating the
> memory for the struct?
>
>
>       Handle  tempH = NULL;
>       Handle tempH2 = NULL;
>       Str255 tempStr = "\ptemp string";
>       OSErr myErr;
>
>       PtrToHand(&tempStr[1], &tempH, tempStr[0]);
>       tempH2 = NewHandle(0);
>       myErr = HandAndHand(tempH, tempH2);
>
First off, IM says "HandAndHand dereferences aHndl [ie tempH] so you must
call HLock ...". This seems really weird to me, but it may be whats causing
your problem.

Second, theres an easier way:
        tempH2 = tempH;
  myErr = HandToHand(&tempH2);

Mark Williams

+++++++++++++++++++++++++++

>From [e-mail] (Hao-yang Wang)
Date: 24 Jan 1995 15:56:43 -0800
Organization: Apple Computer, Inc., Cupertino, California

Mark Williams ([e-mail]) wrote:
: First off, IM says "HandAndHand dereferences aHndl [ie tempH] so you must
: call HLock ...". This seems really weird to me, but it may be whats causing
: your problem.

Yeah, it is weird, for we can always implement a version of HandAndHand
without dereferencing aHndl:

  OSErr myHandAndHand(Handle aHndl, Handle bHndl)
  {   const Size aSize = GetHandleSize(aHndl), bSize = GetHandleSize(bHndl);
      SetHandleSize(bHndl, bSize + aSize);
      const OSErr err = MemError();
      if (err == noErr)
          BlockMoveData(*aHndl, *bHndl + bSize, aSize);
      return err;
  }

As you can see, aHndl needs to be non-purgeable, but does not need to be
locked.

I always use this implementation instead of calling to OS Utilities.


Hao-yang Wang
Pai Technology, Inc.
Taipei
[e-mail]

---------------------------

>From [e-mail] (Lawrence D9Oliveiro)
Subject: MacOS  SDK quick impressions
Date: Tue, 17 Jan 1995 12:00:47 +1300
Organization: University of Waikato

I just received my copy of the new MacOS Software Developer's Kit CD. This
is the one where they pack 30 different developer kits on one disc for the
subscription price of US$299 per year. APDA has a special offer on until
the end of this month, where if you are an ETO subscriber or you bought
any SDK product after 17 October '93, you can get the first year's MacOS
SDK subscription for half price.

Here are some quick notes about what's on it:

* System 7.5, including both QuickDraw GX and PowerTalk software.
* QuickTime, both 1.6.1 and 2.0. You get DocViewer IM volumes, some sample
movies and tools and stuff that were on earlier QuickTime CDs (not 2.0).
You get the 2.0 interfaces, but no 2.0 documentation.
* QuickDraw GX--everything that was on the GX developer kit CD seems to be
there, EXCEPT the DocViewer IM volumes (major omission). You do get the
nifty animated fonts.
* Apple Guide. Yeah, I know it's available free on the net, but not
everybody is in a position to download 30MB of stuff.
* AOCE--looks like everything that was on the developer kit CD is there,
including the DocViewer IM volumes.
* Macintosh Easy Open--well, that's one developer kit I won't have to buy. :-)
* Open Transport 1.0d13, MacTCP 2.0.4--same as you get on ETO.
* Control Strip software, interfaces and documentation, and source for
Martin Minow's "MacCalendar" module.
* Telephone Manager 1.0, including documentation and source for a sample
program called "Stiletto". Hmm, maybe I should actually look at it and
find out what it's about sometime...
* Sound Manager 3.0, including a DocViewer version of IM:Sound. This new
IM volume documents Sound Manager 3.0, including how to write "Sound" and
"Audio" components, as well the Speech Manager. It basically obsoletes all
previous sound-related documentation, so it's worth getting.
* PlainTalk 1.3 software, interfaces and documentation. This includes both
text-to-speech and speech recognition.
* MIDI Manager 2.0.2 software, interfaces and documentation.
* Documentation on "Designing PCI Cards & Drivers" (if you're into that
sort of thing...).
* AppleSearch client software and API interfaces and documentation.
* AppleShare server API interfaces and documentation.
* AppleTalk Remote Access API interfaces and documentation, both versions
1.0 and 2.0 (no software).
* Installer 4.0.3 software, interfaces and documentation.

There're quite a few other things as well, which don't seem so exciting to
me. It's unlikely that anyone would find *everything* useful, but if there
are three or four things there that are of value to you, then it's
probably worth getting this SDK subscription, instead of the individual
SDKs.

Lawrence D'Oliveiro                       fone: [phone]
Computer Services Dept                     fax: [phone]
University of Waikato            electric mail: [e-mail]
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+13:00

+++++++++++++++++++++++++++

>From [e-mail] (Lawson English)
Date: 19 Jan 1995 21:04:53 GMT
Organization: Primenet

Lawrence D9Oliveiro ([e-mail]) wrote:
: I just received my copy of the new MacOS Software Developer's Kit CD. This
: is the one where they pack 30 different developer kits on one disc for the
: subscription price of US$299 per year. APDA has a special offer on until
: the end of this month, where if you are an ETO subscriber or you bought
: any SDK product after 17 October '93, you can get the first year's MacOS
: SDK subscription for half price.

: Here are some quick notes about what's on it:
[stuff deleted]


You forgot the most important part: the licensing agreement allows you to
distribute most of the system extensions as part of the subscription price.


Two notable exceptions are QT 2.0 and PlainTalk... :-(

These are $300/year/app each, which is much better than PlainTalk's old
licensing ost of $1500/year/app, but still doesn't help the games writer
(well, Bungie could afford to distribute QT 2.0 and PlainTalk, even at
the old price, but for most of us...).


In case anyone else is concerned about this, you might call Apple
Licensing and suggest that QT and PlainTalk be included in the package
licensing deal for the SDK CD.



--
- -----------------------------------------------------------------------------
Lawson English                            __  __     ____  ___       ___ ____
[e-mail]                     /__)/__) / / / / /_  /\  / /_    /
                                        /   / \  / / / / /__ /  \/ /___  /
- -----------------------------------------------------------------------------

+++++++++++++++++++++++++++

>From Manuel Veloso <[e-mail]>
Date: Tue, 24 Jan 1995 23:48:55 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

In article <3fmk5l$[e-mail]> Lawson English, [e-mail] writes:
>You forgot the most important part: the licensing agreement allows you to
>distribute most of the system extensions as part of the subscription price.
>

Hmmm. Does the licence allow you to distribute the installer?

Manuel

---------------------------

>From Michael Moore <[e-mail]>
Subject: NIM Routines that Move or Purge Memory
Date: Sun, 15 Jan 1995 19:38:02 GMT
Organization: None

I have been trying to locate a chapter or table in the New Inside
Macintosh set
that has the equivalent of the "Routines that may move or purge memory"
appendix in the Old Inside Macintosh books.  I have the "Inside Macintosh
CD-ROM" but have not been able to find it in any of the books.  The Memory
Manager Overview section warns you of the dangers of "RtmMoPM" and
indicates
that the routines described in NIM will be documented one way or the
other in
their respective chapters, but very few routines actually specify.

I have been searching through the appendices of my Old Inside Mac books
(which
is only a slight pain), but need to find a newer reference for new
routines
described only in the NIM, such as InvalMenuBar.

If you can help cure my blindness in finding the section on the CD on NIM
books, or if you have any other suggestions, I would appreciate it.

-Michael Moore
[e-mail]

+++++++++++++++++++++++++++

>From "Andrew C. Plotkin" <[e-mail]>
Date: Mon, 16 Jan 1995 13:45:07 -0500
Organization: Information Technology Center, Carnegie Mellon, Pittsburgh, PA

Excerpts from netnews.comp.sys.mac.programmer.help: 15-Jan-95 NIM
Routines that Move or P.. Michael [e-mail] (904)

> I have been trying to locate a chapter or table in the New Inside
> Macintosh set
> that has the equivalent of the "Routines that may move or purge memory"
> appendix in the Old Inside Macintosh books.

Heh. We've had this before. I still claim that *every* Toolbox call may
move or purge memory, with a small handful of "obvious" exceptions
(BlockMove, BlockMoveData, HLock, HUnlock, HPurge, HNoPurge.) (And the
bit-setting traps like BAnd which I never use, since I program in C.)

There are undoubtedly other routines that don't move memory, but many
fewer that are *guaranteed* to never move memory in the future, and it's
not worth my time to worry about seeking them out.

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."

+++++++++++++++++++++++++++

>From [e-mail] (John W. Baxter)
Date: Mon, 16 Jan 1995 18:50:05 -0800
Organization: Internet for the Olympic Peninsula

In article <[e-mail]>, "Andrew C. Plotkin"
<[e-mail]> wrote:

> Excerpts from netnews.comp.sys.mac.programmer.help: 15-Jan-95 NIM
> Routines that Move or P.. Michael [e-mail] (904)
>
> > I have been trying to locate a chapter or table in the New Inside
> > Macintosh set
> > that has the equivalent of the "Routines that may move or purge memory"
> > appendix in the Old Inside Macintosh books.
>
> Heh. We've had this before. I still claim that *every* Toolbox call may
> move or purge memory, with a small handful of "obvious" exceptions
> (BlockMove, BlockMoveData, HLock, HUnlock, HPurge, HNoPurge.) (And the
> bit-setting traps like BAnd which I never use, since I program in C.)

And even if Apple's version doesn't move memory (and you've made certain
that getting to any glue doesn't), you don't *know* in advance that some
<fill in description of your choice> hasn't written a patch, installed by
the one of your users most likely to make midnight phone calls, which
causes the call to move memory.

Even that is unlikely to apply to the calls you list (your user will
likely have called someone else at midnight, first).

   --John

--
John Baxter    Port Ludlow, WA, USA  [West shore, Puget Sound]
       Isn't C fun?
   [e-mail]

+++++++++++++++++++++++++++

>From Michael Moore <[e-mail]>
Date: Fri, 20 Jan 1995 03:02:15 GMT
Organization: None

In article <[e-mail]> Andrew C. Plotkin,
[e-mail] writes:
>Excerpts from netnews.comp.sys.mac.programmer.help: 15-Jan-95 NIM
>Routines that Move or P.. Michael [e-mail] (904)
>
>> I have been trying to locate a chapter or table in the New Inside
>> Macintosh set
>> that has the equivalent of the "Routines that may move or purge memory"
>> appendix in the Old Inside Macintosh books.
>
>Heh. We've had this before. I still claim that *every* Toolbox call may
>move or purge memory, with a small handful of "obvious" exceptions
>(BlockMove, BlockMoveData, HLock, HUnlock, HPurge, HNoPurge.) (And the
>bit-setting traps like BAnd which I never use, since I program in C.)
>
>There are undoubtedly other routines that don't move memory, but many
>fewer that are *guaranteed* to never move memory in the future, and it's
>not worth my time to worry about seeking them out.

Well I suppose that information is useful if you're writing some
applications, but folks writing INITs that need to perform periodic
tasks often need to worry about which calls can be made when they
get their opportunity to run at interupt time.

-Michael

+++++++++++++++++++++++++++

>From [e-mail] (John W. Baxter)
Date: Fri, 20 Jan 1995 13:23:18 -0800
Organization: Internet for the Olympic Peninsula

In article <[e-mail]>, Michael Moore <[e-mail]> wrote:

> Well I suppose that information is useful if you're writing some
> applications, but folks writing INITs that need to perform periodic
> tasks often need to worry about which calls can be made when they
> get their opportunity to run at interupt time.
>

And in the possible presence of bogus patches which turn "safe" traps into
unsafe one, the answer is that no patchable trap is safe.  On 68K, that's
"no trap".  In the absence of INITs and other patching agents you don't
trust, the only thing you have to worry about is safe traps becoming
unsafe (SysBeep () comes to mind...it may now load a resource...in 1984 it
couldn't (in the absence of a patch, of course).

   --John

--
John Baxter    Port Ludlow, WA, USA  [West shore, Puget Sound]
       Isn't C fun?
   [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Ivan Cavero Belaznde)
Date: 20 Jan 1995 20:20:13 GMT
Organization: Avid Technology, Inc.

In article <[e-mail]>, "Andrew C. Plotkin"
<[e-mail]> wrote:

> Excerpts from netnews.comp.sys.mac.programmer.help: 15-Jan-95 NIM
> Routines that Move or P.. Michael [e-mail] (904)
>
> > I have been trying to locate a chapter or table in the New Inside
> > Macintosh set
> > that has the equivalent of the "Routines that may move or purge memory"
> > appendix in the Old Inside Macintosh books.
>
> Heh. We've had this before. I still claim that *every* Toolbox call may
> move or purge memory, with a small handful of "obvious" exceptions
> (BlockMove, BlockMoveData, HLock, HUnlock, HPurge, HNoPurge.) (And the
> bit-setting traps like BAnd which I never use, since I program in C.)

I disagree with that claim, actually. Part of the problem here is that
we're talking about two sets of calls:
   - Calls that may move memory (so that they can be called after a
      potentially unsafe handle dereference without invalidating the
      dereference).
   - Calls that cannot be called at interrupt/preemptive time, such as a
      completion routine, time mgr task, or VBL task (irrespectively of
      whether they move memory or not).

The criteria for the first kind of calls is that none of the calls below
them in the control flow tree call one of:
         Alloc calls: NewHandle, NewPtr, ReserveMem.
         Move calls: HLockHi, MoveHHi.
         Size change calls: SetHandleSize, SetPtrSize, ReallocateHandle.
         Squeeze calls: MaxMem, CompactMem, PurgeMem.

The criteria for the second one is tighter (the second set is a subset of
the first set). Not only must they not move memory but they cannot rely
on unlocked handles being valid: this means things like HUnlock, HLock, etc,
as well as other seemingly safe routines (EmptyRgn, GetNextDevice,
GetMaxDevice). Note that the first set of calls is mostly a curiousity,
since their purpose is to ensure the validity of a "cached" dereference
for the most part, and it is the second set of calls which is really
useful (until we get truly preemptive multitasking).

I believe that in most cases it's possible to determine whether a given
call meets either criteria. Most I/O OS calls, for example, are interrupt
safe (Open does, since it can allocate FCBs), since they are callable from
completion procs when running async, and _Read and _Write must be callable
from page fault handlers. Additionally, while people will point out that
patches can make calls that don't move memory actually move it, I believe
those patches are buggy and should be fixed, just like any other patch
which makes invalid assumptions about what it may or may not do (for
example, a well-known hierarchical apple menu utility patched Open and
attempted to save the port inside the patch; the problem is that it's
totally legal, though uncommon, to call Open without having valid QD
globals).

I do believe that the focus of the "list" has to change, however - it
should be a list of routines that do *not* move or purge memory, and are
interrupt safe, rather than the opposite, as they appeared in the original
IM. The net's a great resource in this aspect.

> There are undoubtedly other routines that don't move memory, but many
> fewer that are *guaranteed* to never move memory in the future, and it's
> not worth my time to worry about seeking them out.

It all depends on the task, I guess: if you're trying to do time critical
things via interrupt handlers or time manager tasks, it behooves you to
seek them out - otherwise, it's impossible to have a clear picture of what
can or cannot be done at interrupt time.

HTH,

-Ivan
- ---
Ivan Cavero Belaznde ([e-mail])
Avid VideoShop Project Lead
Avid Technology, Inc.

---------------------------

>From Karl Goiser <[e-mail]>
Subject: Simulating Drag-to-Trash
Date: 18 Jan 1995 22:47:47 GMT
Organization: self

Hi All,

I was just wondering if anyone knew how to programatically simulate
dragging a file to the trash.  I know how to find the trash can for
a particular volume and to _move_ it there - but you don't get the
'put away' option like you do when you drag the fiel in the Finder.

Thanks in advance!

Karl Goiser
CompuTechnics

+++++++++++++++++++++++++++

>From [e-mail] (Lawrence D9Oliveiro)
Date: Thu, 19 Jan 1995 13:56:18 +1300
Organization: University of Waikato

In article <3fk5qj$[e-mail]>, Karl Goiser
<[e-mail]> wrote:

>I was just wondering if anyone knew how to programatically simulate
>dragging a file to the trash.  I know how to find the trash can for
>a particular volume and to _move_ it there - but you don't get the
>'put away' option like you do when you drag the fiel in the Finder.

Let me see if I understand what you mean: you want to be able to move a
file or folder into the trash folder on a volume, such that the Finder's
"Put Away" command will return it to its original location?

One way to do this is to have the Finder do it, by sending it the
appropriate AppleEvent. The easiest way to achieve this would be via
AppleScript.

If you want to do it yourself, then I believe the following should work:

* Do a GetCatInfo on the object.
* Set the ioFlXFndrInfo.fdPutAway field in the catalog info to the item's
current parent directory ID.
* Do a SetCatInfo with the new info.
* Then do the CatMove call to move the item into the Trash.

Disclaimer: I haven't tried this, so for all I know there may be more to
"Put Away" support than I think.

Lawrence D'Oliveiro                       fone: [phone]
Computer Services Dept                     fax: [phone]
University of Waikato            electric mail: [e-mail]
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+13:00

---------------------------

>From [e-mail] (Ingemar Ragnemalm)
Subject: Sprite Animation Toolkit 2.3a2 available
Date: 25 Jan 1995 23:21:47 GMT
Organization: (none)


Sprite Animation Toolkit (SAT) version 2.3a2 is now available by anonymous
ftp from ftp.lysator.liu.se, in /pub/mac/sat.

SAT is a freeware programmer's library for creating animations (e.g. games)
with sprites, as in most 2D games. It has already been used in numerous
released games, like Bachman, Ingemar's Skiing Game, Asterax, Missions
Of The Reliant and many others.

SAT is free for any kind of use, **including commercial use**, as long as
credits are given and a free copy is sent or made available to me.

SAT has a simple programming interface, letting you use a very small set
of calls for simple programs, but with many hooks and special routines for
advanced programmers. With SAT, you can support old Macs, different screen
depths etc with little effort.

It includes a fair number of demos, from extremely simple introductory demos
to a full, complete game (HeartQuest).

SAT includes libraries for Think Pascal, Think C/Symantec C++, CodeWarrior
Pascal and C/C++. The Think Pascal library is in MPW .o format, but I am not
able to verify if it can be used with MPW:

SAT 2.3a2 still does not include a PowerMac version, but that is almost
there - really! The only problem left to make the PowerMac SAT version
useable is a glitch in the sound routines, which makes the animation
jumpy when sounds are played. When that is solved, the next SAT version
will include a PowerMac library for CodeWarrior. BTW, if someone has a
good blitter for masked sprites on the PowerMac, I'm interested!

Even though it still has the "alpha" mark, I believe that SAT 2.3a2 is
quite stable and performs well. If you can confirm this, or report problems,
I would be grateful! No feedback means slower progress.

--
- -
Ingemar Ragnemalm, PhD
Image processing, Mac shareware games
E-mail address: [e-mail] or [e-mail]

---------------------------

>From [e-mail] (John Sudderth)
Subject: StandardGetFile behavior
Date: Thu, 19 Jan 1995 12:37:55 -0600
Organization: CSC

System 7.5 changes the behavior of StandardGetFile depending on the
Documents setting in the General Controls CP. It seems to override my
setting the 2 low memory globals you can set to point to a specific
folder. Is there anyway to force StandardGetFile to point to a specific
folder regardless of that setting? Has anyone written a DlgHook that can
do this?

+++++++++++++++++++++++++++

>From [e-mail] (Brian Stern)
Date: 20 Jan 1995 04:57:53 GMT
Organization: The University of Texas at Austin, Austin, Texas

In article <[e-mail]>,
[e-mail] (John Sudderth) wrote:

< System 7.5 changes the behavior of StandardGetFile depending on the
< Documents setting in the General Controls CP. It seems to override my
< setting the 2 low memory globals you can set to point to a specific
< folder. Is there anyway to force StandardGetFile to point to a specific
< folder regardless of that setting? Has anyone written a DlgHook that can
< do this?

A DlgHook to do this is easy.  Leave the low mem globals behind.

Just set up the sfFile field in your StandardFileReply record to point to
the appropriate place BEFORE calling StandardGetFile.  Then in your hook
when you get the sfFirstCall item change it to sfHookChangeSelection.
Something like this:


void
CustomGet( FSSpec &newFileSpec )
{
   Point          where = { -1, -1 };
   StandardFileReply sfReply;
   SFTypeList        myTypes;

   myTypes[0] = 'TEXT';

   sfReply.sfFile = newFileSpec;

   CustomGetFile( nil, 1, myTypes, &sfReply, 200, where, theDlgHookUPP,
               nil, nil, nil, nil );
}

pascal short
MyDlgHook( short item, DialogPtr, Ptr )
{
   if ( item == sfHookFirstCall )
      item = sfHookChangeSelection;

   return item;

}

--
Brian  Stern  :-{)}
Toolbox commando and Menu bard
[e-mail]

---------------------------

>From [e-mail] (J. Babb)
Subject: What causes "odd address 0x40be14" error?
Date: Mon, 09 Jan 1995 10:24:16 -0800
Organization: Usually Post-it notes and a Larsen calendar


Hi Folks,
     Running Think C 5.0.2 on a Mac Plus 4/80(System 6.0.8, Finder 6.1.8)
with or without Macsbug loaded, Mark & Reed's Hello2 program compiles, but
dies in the TC debugger with an odd address error at
SetPort(gPictureWindow);, namely address 0x40BE14.

Well, that looked like an even number to me! And I couldn't figure out why
a ToolBox call would fail.

So I looked for programs that called SetPort that also worked. Think C's
demo program - BullsEye worked, but it calls NewWindow, not GetNewWindow.
So I recompiled with NewWindow and Hello2 now works. I'd still like to
know why I got the odd address error.

/*gPictureWindow=GetNewWindow ( BASE_RES_ID , NIL_POINTER , MOVE_TO_FRONT );
       The previous line generates a run time error of odd address */

gPictureWindow=NewWindow ( 0L, &windowBounds, "\phello2", true,
noGrowDocProc, (WindowPtr) -1L, true, 0 );

SetPort ( gPictureWindow );

This works. But of course doesn't use the WIND resource I made.

Could somebody give me Dave Mark's or Cartwright Reed's email addr? I'd
like to get an errata sheet, and pose some of these questions to them,
since they've probably answered them already. Maybe there's a Think C 5.0
FAQ !!   :-)

--
                             Jeff Babb
"Mr. Babb, you sure ask a lotta questions." - Roseanna Roseannadanna
   [e-mail]  Flames to dev/null/heatsink/asbestos

+++++++++++++++++++++++++++

>From [e-mail] (Ken Long)
Date: Mon, 9 Jan 1995 20:23:11 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

J. Babb ([e-mail]) wrote:

: Could somebody give me Dave Mark's or Cartwright Reed's email addr? I'd
: like to get an errata sheet, and pose some of these questions to them,
: since they've probably answered them already. Maybe there's a Think C 5.0
: FAQ !!   :-)

[e-mail].

But he proclamed all the Primer 1 source as freeware, and the whole thing
can be downloaded from AOL.  TC 7 projects, but easily backgradable.

Check to make sure the ID of the window in the .rsrc file is the same as
the ID called for in the source.  If BASE_RES_ID is 400 and your window
ID is 128 you'll get the odd address error.

It's not "odd vs. even" - it's "That's odd!  It's not there."  If someone
gave you the address of Symantec, and you went there and only found a
vacant lot, wouldn't you say that was an odd address for Symantec?

-Ken-


+++++++++++++++++++++++++++

>From [e-mail] (J. Babb)
Date: Mon, 09 Jan 1995 16:53:20 -0800
Organization: Usually Post-it notes and a Larsen calendar

In article <[e-mail]>, [e-mail] (Ken Long) wrote:

> J. Babb ([e-mail]) wrote:
>
> : Could somebody give me Dave Mark's or Cartwright Reed's email addr? I'd
> : like to get an errata sheet, and pose some of these questions to them,
> : since they've probably answered them already. Maybe there's a Think C 5.0
> : FAQ !!   :-)
>
> [e-mail].

THANKS very much!


> But he proclamed all the Primer 1 source as freeware, and the whole thing
> can be downloaded from AOL.  TC 7 projects, but easily backgradable.
>
> Check to make sure the ID of the window in the .rsrc file is the same as
> the ID called for in the source.  If BASE_RES_ID is 400 and your window
> ID is 128 you'll get the odd address error.
It definitely is 400 in the call and in the WIND resource.


>
> It's not "odd vs. even" - it's "That's odd!  It's not there."  If someone
> gave you the address of Symantec, and you went there and only found a
> vacant lot, wouldn't you say that was an odd address for Symantec?
>
> -Ken-

Really????? Cause as I understand it byte alignment, and padding are
important so that a routine does not begin on an odd byte boundary. I
think Think C is trying to tell me that the call is misaligned. Anyway it
the precompiled headers that resolve a routine's address isn't it?. If so
how do I correct the header?

Thanx again for your time.

--
                             Jeff Babb
"Mr. Babb, you sure ask a lotta questions." - Roseanna Roseannadanna
   [e-mail]  Flames to dev/null/heatsink/asbestos

+++++++++++++++++++++++++++

>From [e-mail] (Ken Long)
Date: Tue, 10 Jan 1995 03:00:46 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

J. Babb ([e-mail]) wrote:
: It definitely is 400 in the call and in the WIND resource.

: Really?????

I don't know - don't believe anything *I* say!  Check it out for yourself.
But, any time I EVER got an odd adress error, it was somthing about a
misplaced, missed pointed to, mis... something resource that caused it.

: Cause as I understand it byte alignment, and padding are
: important so that a routine does not begin on an odd byte boundary. I
: think Think C is trying to tell me that the call is misaligned. Anyway it
: the precompiled headers that resolve a routine's address isn't it?. If so
: how do I correct the header?

Again, I don't know, but if you InitMac, SetUpMenus, SetUpWindows, and in
your set up window routine you call a correctly syntaxed GetNewWindow,
then how could something get "odd?"

GetNewWindow has 3 arguments.  Any of the three could have something
*earlier* about them contributing to the error, which didn't show 'til
the debugger run.  If you'e eliminated the resID thing, then it's
something else.  Could even be something so unblatant as a ';' after a
define.  I've downloaded old source that had invisible characters in the
source, or one so far off the right of the screen they didn't show easily.

Anyway, probably nothing so bizzare in your source.

Another place the odd address would show, that I've seen, is in a pascal
to C port, where you're gauranteed plenty of omitted characters and
operators.  Odd address will show in the debugger (if not a crash) if the
ampersand is missing from in front of the second argument to "FindWindow"
- namely "whichWindow" (the most common).

That's "at the address of" whichWindow.  Think C won't catch that one,
but MW will.

Another is menu setup routines.  Some old, funky source might odd-address
in one, so I'll just replace the whole routine and not even bother trying
to track down the problem.  Process of elimination in action again.

-Ken-

+++++++++++++++++++++++++++

>From Jens Alfke <[e-mail]>
Date: Mon, 9 Jan 1995 23:37:27 GMT
Organization: Apple Computer

J. Babb, [e-mail] writes:
> dies in the TC debugger with an odd address error at
> SetPort(gPictureWindow);, namely address 0x40BE14.
> Well, that looked like an even number to me! And I couldn't figure out why
> a ToolBox call would fail.

40be14 is the address of the code that was writing to the offending odd
address. And most Toolbox calls can fail if you give them bogus inputs, such
as bad pointers or pointers to bad data structures, or if the system has been
damaged i.e. a corrupted heap.

It's quite possible this is a bug in the example code, since the odd address
error only occurs on 68000s, not on 020s or higher, and some people forget to
test their code on a real live 68000 before shipping it.

--Jens Alfke                           [e-mail]
                   "A man, a plan, a yam, a can of Spam ... Bananama!"

+++++++++++++++++++++++++++

>From [e-mail] (Robert A. Uhl)
Date: 10 Jan 1995 22:36:58 GMT
Organization: University of Denver

In article <[e-mail]>,
Jens Alfke  <[e-mail]> wrote:

[snip]

>It's quite possible this is a bug in the example code, since the odd address
>error only occurs on 68000s, not on 020s or higher, and some people forget to
>test their code on a real live 68000 before shipping it.

  Tell me about. I have a Classic (Sym C/C++ 6.0 actually works on it!
The C part anyway. C++ crashes on it and my father's IIsi), and just
about all of the apps that I download crash it with address errors or
ubdefined A-traps. Annoying as hell.

--
- ------------------------------------------------------------------------
| Bob Uhl | Spectre                  | `In touto nika' +                 |
| U of D  | Baron Robert von Raetzin | http://mercury.cair.du.edu/~ruhl/ |
- ------------------------------------------------------------------------

+++++++++++++++++++++++++++

>From [e-mail] (Jens Alfke)
Date: Tue, 10 Jan 1995 23:14:43 GMT
Organization: Apple Computer, Inc.

[e-mail] (Ken Long) wrote:
> > It's not "odd vs. even" - it's "That's odd!  It's not there."  If someone

No, that's wrong. It _does_ too mean odd as in the opposite of even. The
68000 CPU cannot read a 16 or 32-bit value from an odd address. The 020
and later have the hardware support to do this, so they don't generate odd
address errors.

[e-mail] (J. Babb) wrote:
> Really????? Cause as I understand it byte alignment, and padding are
> important so that a routine does not begin on an odd byte boundary.

Generall the routine is okay but the code in the routine is trying to read
or write data to an odd address; an instruction like
   tst.w (a0)
would fail if a0 contained, for instance, 0x50FF8001.
It's also possible to get an odd address error trying to execute code if a
bogus jump or return instruction tries to jump to an odd address. But this
is rarer.

--Jens Alfke

+++++++++++++++++++++++++++

>From [e-mail] (Ken Long)
Date: Mon, 16 Jan 1995 16:14:27 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

Jens Alfke ([e-mail]) wrote:
: No, that's wrong. It _does_ too mean odd as in the opposite of even. The
: 68000 CPU cannot read a 16 or 32-bit value from an odd address. The 020
: and later have the hardware support to do this, so they don't generate odd
: address errors.

I have a 68020 and I get odd address errors.  So what gives?

-Ken-

+++++++++++++++++++++++++++

>From [e-mail] (Patrick Stadelmann)
Date: 17 Jan 95 08:07:17 MET
Organization: University of Neuchatel

In article <[e-mail]>, [e-mail] (Ken Long) wrote:

> Jens Alfke ([e-mail]) wrote:
> : No, that's wrong. It _does_ too mean odd as in the opposite of even. The
> : 68000 CPU cannot read a 16 or 32-bit value from an odd address. The 020
> : and later have the hardware support to do this, so they don't generate odd
> : address errors.
>
> I have a 68020 and I get odd address errors.  So what gives?
>

The 68020 won't generate an address error if you READ or WRITE
a 16 or 32-bit value at an odd address. But it will if you
try to EXECUTE code at an odd addres. On the 680x0, the instructions
must always be aligned on a word.

Patrick

--
Patrick Stadelmann <[e-mail]>

+++++++++++++++++++++++++++

>From [e-mail] (Greg Marriott)
Date: Wed, 18 Jan 1995 02:11:31 -0800
Organization: General Magic, Inc.

In article <[e-mail]>, [e-mail] (Ken Long) wrote:
> Jens Alfke ([e-mail]) wrote:
> : No, that's wrong. It _does_ too mean odd as in the opposite of even. The
> : 68000 CPU cannot read a 16 or 32-bit value from an odd address. The 020
> : and later have the hardware support to do this, so they don't generate odd
> : address errors.
>
> I have a 68020 and I get odd address errors.  So what gives?

As Jens pointed out in the same message you quoted above:

> : It's also possible to get an odd address error trying to execute code if a
> : bogus jump or return instruction tries to jump to an odd address. But this
> : is rarer.

So if some bug trashes data on the stack, for example, then a return
address for a subroutine might get hammered and the RTS instruction will
generate an address error exception.

Greg
--
Greg Marriott
Just Some Guy
General Magic, Inc.

Disclaimer: My opinions are not necessarily the same as General Magic's.
            (can a company even HAVE an opinion?)

+++++++++++++++++++++++++++

>From Mark Williams <[e-mail]>
Date: Mon, 23 Jan 1995 08:41:55 GMT
Organization: Streetly Software


In article <[e-mail]>, Ken Long writes:

>
> Jens Alfke ([e-mail]) wrote:
> : No, that's wrong. It _does_ too mean odd as in the opposite of even. The
> : 68000 CPU cannot read a 16 or 32-bit value from an odd address. The 020
> : and later have the hardware support to do this, so they don't generate odd
> : address errors.
>
> I have a 68020 and I get odd address errors.  So what gives?

68020 and above can read/write data at odd addresses. They still generate an
odd address error if you try to _execute_ an instruction at an odd address.

Mark Williams

---------------------------

>From [e-mail] (Anders Wahlin)
Subject: Where can I find some game source code?
Date: Fri, 13 Jan 1995 07:52:04 GMT
Organization: Hum Fak:s Dataservice

I'd like to learn about the techniques on how to make a simple game. I
think that the only way to learn this is to look at other source codes?
I've looked at the Tetris Light source code, but there has to be more than
that? So, does anyone know where to find source codes, informations etc.
on how to make a game?

Any help is appreciated. Thank you.

--
Anders Wahlin
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Yan Lee)
Date: 13 Jan 1995 14:39:20 GMT
Organization: Boston University

Anders Wahlin ([e-mail]) wrote:
: I'd like to learn about the techniques on how to make a simple game. I
: think that the only way to learn this is to look at other source codes?
: I've looked at the Tetris Light source code, but there has to be more than
: that? So, does anyone know where to find source codes, informations etc.
: on how to make a game?

: Any help is appreciated. Thank you.


There is cheesetoast, which is a parody of asteroids.  I am not sure how
the game is like ( i haven't played the latest version ) but the
animation seemed nice.

There is also Arashi, an excellent port of Tempest.  I think it uses a
vector based engine.  1 meg worth of code there.

The games are there via gopher to gopher.archive.umich.edu.  The source
for cheesetoast is there also.  I think you have to ask for the Arashi
source directly from the writers.  I remember an older version of the
Arashi's source being at sumex-aim.stanford.edu.

Tony


+++++++++++++++++++++++++++

>From [e-mail] (Ken Long)
Date: Sat, 14 Jan 1995 00:52:35 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

: Anders Wahlin ([e-mail]) wrote:
: : I'd like to learn about the techniques on how to make a simple game. I
: : think that the only way to learn this is to look at other source codes?
: : I've looked at the Tetris Light source code, but there has to be more than
: : that? So, does anyone know where to find source codes, informations etc.
: : on how to make a game?

There are a few more, around - some complete and some not.

I got the source for MacMan - a B/W but excellent rendition of PacMan,
from the author for $15.  Heluvadeal!

SpriteWorld has some example game source (incomplete) similar to CheeseToast.
It also has some Breakout sources in it.

Sprite Animation Toolkit has some C sources for much of the functionality
of games, like SpaceInvaders, and some others.  It also has complete
Pascal source for HeartQuest - a "CrystalQuest" type game.

There are Pong sources, around - could be worked up into something better
and more sophisticated.

There are "Minefield" sources on the net.

John Calhoun released several of his Pascal game sources, and they are
available at various places.

There are a few good card game sources around, to.  On guy sent me a
Think C 4 source for a Hearts game, to my local board, because he
couldn't get it to run in Think C 5.  So I got it running and sent it
back and retained a copy myself.  It was labelled "free for non-commercial
use" by the authors.

Write to authors of free games and ask if you can have the source.  I've
done this and have gotten some excellent sources.  Also, write authors of
shareware and ask if you can buy theirs on a non-distribution basis
(personal use, only).  That works, sometimes.

Along these lines, there were hundreds of old games that authers put out
free when the Mac first came out.  They wanted a little money as
shareware, but by todays standards the games might look like 7th graders
wrote them.  If the author got to busy, or got off into some other aspect
of the Mac, or something else, he may now just give the source for the
old game away if asked.  Some of these old games were funky and some were
cool in their day, but any could be modernized, colorize and "sophitized"
and otherwise revived.

An example of this is the old Maxwell game.  It was a DA, for one thing.
There were tow rectangles with randomly moving sprites in them, with a
separator bar between rects.  Mousedown removed the separator allowing
sprite to enter the other rect.  Plain, simple, funky - but the idea was
good.  Make it 4 rects with keys to toggle the separators, add variuos
levels, colorize, etc.  See?  many software products today had their
roots in old sources like those.

Sometimes some functionality in a non-game source would lend itself to a
game element, so, in light of that, get every example source you can
(eventually).  Like something that draws a grid, then inverts rectangles
on mouse-clicks, could be used in a concentration or some such game.  See?

What sort of game are you leaning toward?  Maybe someone could steer you
toward sources closer to that type.  There are probably a lot more around
that I didn't mention, because my "gray region" isn't what it used to be.

-Ken-

+++++++++++++++++++++++++++

>From [e-mail] (Anders Backman)
Date: 14 Jan 1995 17:10:52 GMT
Organization: Macademic Computer AB

In article <[e-mail]>,
[e-mail] (Anders Wahlin) wrote:

> I'd like to learn about the techniques on how to make a simple game. I
> think that the only way to learn this is to look at other source codes?
> I've looked at the Tetris Light source code, but there has to be more than
> that? So, does anyone know where to find source codes, informations etc.
> on how to make a game?
>
> Any help is appreciated. Thank you.
>
> --
> Anders Wahlin
> [e-mail]

There is a shareware development package called SpriteWorld, probably at
sumex-aim.stanford.edu. It contains two semifinished games moulded on
Asteroids and Breakout. The well written documentation is styled like the
old Inside macintosh books and veru easy to use. If you are interested in
doing arcade style games this is well worth looking into, but to almost no
use if you are going to do a flight-sim or Marathon clone.

/Anders Backman

+++++++++++++++++++++++++++

>From [e-mail] (David Woodall)
Date: Sat, 14 Jan 95 14:26:00 -0800
Organization: CES Internet Gateway

KL> From: [e-mail] (Ken Long)
KL> : Anders Wahlin ([e-mail]) wrote:
KL> : : I'd like to learn about the techniques on how to make a simple game. I
KL> : : think that the only way to learn this is to look at other source
KL> codes? : : I've looked at the Tetris Light source code, but there has to
KL> be more than : : that? So, does anyone know where to find source codes,
KL> informations etc. : : on how to make a game?

There is some source code at one of Apple's anonomyous FTP sites.
ftp.info.apple.com has some source code and so documentation.  Look in the
Development folder.





+++++++++++++++++++++++++++

>From [e-mail] (Bill the Cat)
Date: Thu, 19 Jan 1995 08:44:07 -0800
Organization: Larryville

In article <[e-mail]>, [e-mail] (Ken Long)
wrote:

> : Anders Wahlin ([e-mail]) wrote:
> : : I'd like to learn about the techniques on how to make a simple game. I
> : : think that the only way to learn this is to look at other source codes?
> : : I've looked at the Tetris Light source code, but there has to be more than
> : : that? So, does anyone know where to find source codes, informations etc.
> : : on how to make a game?
>
> There are a few more, around - some complete and some not.
>
> I got the source for MacMan - a B/W but excellent rendition of PacMan,
> from the author for $15.  Heluvadeal!
>
> SpriteWorld has some example game source (incomplete) similar to CheeseToast.
> It also has some Breakout sources in it.
>
> Sprite Animation Toolkit has some C sources for much of the functionality
> of games, like SpaceInvaders, and some others.  It also has complete
> Pascal source for HeartQuest - a "CrystalQuest" type game.
>

Can someone tell me how I can get a copy of the Sprite Animation Toolkit?

Thanks!  (please E-mail)

Bill

+++++++++++++++++++++++++++

>From [e-mail] (Jeremy Smith)
Date: Thu, 19 Jan 1995 22:15:50 -0600
Organization: Northwestern University, Evanston, IL, US

-snip-
>
> Can someone tell me how I can get a copy of the Sprite Animation Toolkit?
>
> Thanks!  (please E-mail)
>
> Bill

   I'm pretty sure SAT can be found ftp://sumex-aim.stanford.edu:info-mac
in the dev directory.  If it's not there, look in umich or search this
newsgroup for postings by Ingemar, (I can't seem to find his e-mail
address) the author of SAT, and ask him.

+++++++++++++++++++++++++++

>From [e-mail] (Ingemar Ragnemalm)
Date: 22 Jan 1995 11:47:50 GMT
Organization: (none)

[e-mail] (Jeremy Smith) writes:

>> Can someone tell me how I can get a copy of the Sprite Animation Toolkit?

>   I'm pretty sure SAT can be found ftp://sumex-aim.stanford.edu:info-mac
>in the dev directory.  If it's not there, look in umich or search this
>newsgroup for postings by Ingemar, (I can't seem to find his e-mail
>address) the author of SAT, and ask him.

Last time I looked, SAT 2.1.2 was available just where Jeremy says at Sumex,
and at UMich too. The latest version, 2.3a1 (soon to be replaced by 2.3a2,
as soon as I have verified that the demos work with MetroWerks C) is available
from ftp.lysator.liu.se, in pub/mac/sat. It seems as if those newer versions
are stable enough to replace 2.1.2 any time now.

--
- -
Ingemar Ragnemalm, PhD
Image processing, Mac shareware games
E-mail address: [e-mail] or [e-mail]

---------------------------

End of C.S.M.P. Digest
**********************